In the traditional telephone carrier operating model, calls between Local Exchange Carriers (LECs), or Retail Service Providers (RSPs) are transported by an Inter-Exchange Carrier (IXC). The RSP provides retail telephone services to its end user subscribers on its network. When a RSP end user subscriber calls a telephone number which is not in the RSP's network, the RSP will switch that call to an IXC that will transport the call to the RSP serving the called number to complete the telephone call to the receiving party. The business model for this call scenario starts with the source RSP that switches the call to the IXC. The RSP pays the IXC a fee to transport the call to the destination RSP. The DCC transports the call to the destination RSP which completes the call to the receiving party.
The DCC pays the destination RSP a fee to complete the telephone call. An important operating value added by the DCC is route discovery. The IXC manages a central routing table that enables routing among a multitude of RSPs to any telephone number on the global Public Switched Network (PSTN). This action simplifies operations for the RSP operator whom needs to route to only one IXC to obtain termination to any telephone number in the PSTN. In this document, the operating model described above is referred to as the IXC operating model.
This common telephony business model for the operating model described above is referred to as the Calling Party Pays model. The end user of the source RSP pays a retail service fee to the source RSP. The source RSP pays the IXC a fee to locate and transmit the call to the destination RSP. The IXC pays the destination RSP a termination fee to complete the call. An important aspect of this business model is the role of the IXC as the central routing and billing intermediary among many RSPs. Source and destination RSPs do not have commercial interconnect agreements with one another.
An important commercial value added by the IXC is the clearing of calls (routing and access control) between RSPs, accounting of interconnected calls and settlement of interconnect fees to ensure the destination RSP receives a share of the revenue compensation as expected in the Calling Party Pays business model. Each RSP has a single bilateral interconnect agreement with the IXC which eliminates the costly need for commercial bilateral agreements with every other RSP.
Relative to the conventional IXCs, a new communications model has evolved: The increasing use of Voice over IP (VoIP) communications has made possible a new operating model referred to as the Peer To Peer operating model. The Peer To Peer operating model differs from the IXC operating model because end to end routing and signaling for telephone calls is achieved directly from the source RSP (peer) to the destination RSP (peer) without the need for a central intermediary such as an IXC. Two examples of the Peer To Peer operating model are DUNDi and ENUM. DUNDi (Distributed Universal Number Discovery, www.dundi.com) enables source networks (peers) to discover routes to destination networks (peers) without the need for a central routing directory or intermediary signaling point.
ENUM is the Internet Engineering Task Force (www.itef.org) protocol (RFC 2916) which defines how a source peer may resolve telephone numbers into IP addresses in order to route and signal a VoIP call directly to the destination network (peer). In other words, ENUM is a standard adopted by the Internet Engineering Task Force (IETF) that uses the domain name system (DNS) to map telephone numbers to Web addresses or uniform resource locators (URL). The goal of the ENUM standard is to provide a single number to replace the multiple numbers and addresses for an individual's home phone, business phone, fax, cell phone, and e-mail.
However, while IP technology has enabled the Peer To Peer operating model, there is no scalable mechanism to implement the Calling Party Pays business model with a Peer To Peer operating model. With the Peer To Peer operating model, the Calling Party Pays business model can only be implemented if every RSP (peer) has a bilateral commercial interconnect agreement with every other RSP (peer). Bilateral agreements among RSPs is not practical because the number of commercial peering agreements for all RSPs increases by the square of the number of RSPs (peers) [n*(n−1)/2 where n=number of peers], making large scale peer to peer networks using the Calling Party Pays business model virtually impossible.
Referring now to FIG. 1a, this figure illustrates a VoIP call within a RSP's network. Circle 100 in FIG. 1a represents the RSP network. The RSP network could be a private IP network or a subset of public Internet. The call control point 110 controls calls between the calling and receiving parties by providing calling party authentication, additional service features such as call forwarding, call signaling to the receiving party and generating called detail records to account for the call transaction. One of ordinary skill in the art who is familiar with VoIP technology will recognize that the Call Control Point could be either an H.323 gatekeeper, H.323 EP to EP gateway, SIP proxy, SIP back to back user agent, softswitch, session border controller or any other device which controls routing or signaling between source and destination VoIP devices. Two end user subscribers of the RSP Network are represented by a first telephone 120 with number 14045266060 and second telephone 130 with number 14045724600.
FIG. 1a represents a call scenario where the calling party 120 calls a receiving party 130. The call from the calling party 120 is initiated with a call setup message 400, such as a SIP Invite message to the Call Control Point 110. The Call Control Point determines if, and how, the call should be routed to the receiving party 130. To complete the call to the receiving party 130, the Call Control Point 110, sends a message 410 to the receiving party 130 to complete the call between the calling and called parties. When the RSP provides service to both the calling and called parties, the call can be completed within the RSP's network 100 without the use of facilities provided by another VoIP service provider. In FIG. 1a, inter-IP network peering does not occur.
Referring now to FIG. 1b, this Figure illustrates a VoIP call that requires inter-IP network peering. FIG. 1b includes the Source RSP Network 100, and with elements 110, 120 and 130 that are similar those described in FIG. 1a. Destination RSP Network 200 with Call Control Point 210 is introduced in FIG. 1b. Two end user subscribers of the Destination RSP Network 200 are represented by a third telephone 220 with number 17033089726 and fourth telephone 230 with number 17036054283. The calling party 120 places a call to telephone number 17036054283. The call starts with a call setup message 400 from the calling party 120 to the Call Control Point 110 of the Source RSP Network 100. The Source RSP Network 100 cannot complete the call within its network, since the receiving party 230 is served by the Destination RSP Network 200. Therefore, the source Call Control Point 110, sends a message 420 to the Call Control Point 210 of the Destination RSP Network 200. The destination Call Control Point 210 then sends a message to the receiving party 230 to complete the call.
Completion of the call scenario in FIG. 1b requires peering between the Source RSP 100 and Destination RSP 200 networks. Peering between VoIP networks requires two functions. First, the source IP network 100 must know which destination VoIP network 200 can complete the call. This information is referred to as routing—the source network 100 must know to which IP address the VoIP call should be routed. Routing information can be pre-programmed into the Call Control Point of the source network based on a pre-arranged, bilateral peering agreement between source and destination networks, or discovered in real time using mechanisms such as DUNDi or ENUM referred to previously.
The second function required for peering is access permission. The source network 100 must be permitted to access the destination network 200 to complete the call. Access permission between two IP networks is commonly controlled by the use of an access list at the destination network. The destination network 200 will only accept IP communications from IP addresses in its access control list. Other access control techniques are based on the inclusion of a password or digital signature in the call setup message 420 between the source and destination networks. If the destination network 200 can validate that the password or digital signature can only be from a trusted source, the call or peering transaction can be accepted without the source IP address being included in an access control list.
There are several limitations with this conventional technology used for VoIP interconnection or peering. First, the technique of bilateral peering agreements is difficult to implement when a large number of bilateral peering agreements must be maintained. Real time route discovery techniques such as ENUM or DUNDi provide scalable solutions for inter-peer routing but do not provide scalable mechanisms for inter-peer access control or accounting. Accordingly, there is a need in the art for a scalable technique for inter-peer access control and accounting that is independent of the route discovery mechanism. A further need exists for a reliable scalable mechanism for implementing the Calling Party Pays business model with a Peer to Peer operating model:
A need exists in the art to solve this scalability problem for the Calling Party Pays business model in a Peer To Peer operating model. A need also exists in the art for eliminating or substantially reducing the number of bilateral agreements among RSPs.